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Logistics  Data  Communications  Network.  The  description  should 
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These  documents  describe  the  physical  environment  in  which  the  Front  End 
Processors  for  the  Navy  Logistics  Data  Communications  Network,  must  operate. 
These  descriptions  serve  as  a  framework  for  refinement  upon  which  a  feasi¬ 
bility  study  can  be  based.  It  defines  things  such  as  functions,  traffic  and 
Interfaces  it  must  support.  These  reports  will  also  be  used  to  identify  a 
least  cost  configuration  for  the  system  that  will  still  satisfy  its  require¬ 
ments. 
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1.  INTRODUCTION 
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The  Navy  Fleet  Material  Support  Office  (FMSO)  is  currently 
evolving  an  integrated,  real-time  data  communications  network  to 
provide  a  large  number  of  dispersed  Navy  sites  with  logistics  in¬ 
formation  necessary  for  effective  and  efficient  logistics  support. 
The  Logistics  Data  Communications  Network  (LDCN)  will  enable  re¬ 
mote  sites  to  directly  access  major  logistics  data  bases  at  two 
Inventory  Control  Points  (ICP's).  Programmable  communications 
concentrators  at  selected  remote  sites  will  be  used  for  cost-ef¬ 
fective  interface  of  low  speed  terminals  with  the  computer  com¬ 
plexes  managing  the  data  bases.  These  complexes  each  have  two 
U494  computers,  and  one  also  has  an  IBM  360/65,  and  the  other 
also  has  a  Burroughs  3500. 

FMSO  has  identified  the  need  for  a  Front  End  Processor  (FEP) 
at  each  of  these  complexes  to  serve  the  communications  functions 
for  the  main  computers.  However,  the  size,  power,  and  configug 
ration  of  the  computer  system  needed  for  the  FEP  is  not  clear. 

Of  particular  interest  in  this  respect  is  the  feasibility  of 
using  a  minicomputer  system  to  support  the  traffic  and  functions 
envisioned  for  the  FEP.  The  purpose  of  this  study  is  to  determine 
this  feasibility;  and,  if  the  feasibility  is  affirmative,  to  iden¬ 
tify  a  least,  cost  configuration  for  the  minicomputer  system  that 
will  satisfy  the  FEP  requirements,  f  -  — ■  . .  . 
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The  viability  of  a  minicomputer  system  as  an  FEP  in  the 
LDCN  will  depend  on  many  factors,  including  the  functions  as¬ 
sociated  with  the  FEP,  the  traffic  it  must  support,  and  its 
interfaces  with  other  system  elements.  This  memorandum  gives 
a  preliminary  description  of  the  network  environment  in  which 
the  FEP  will  operate,  the  functions  associated  with  the  FEP, 
the  traffic  it  must  support,  and  a  proposed  FEP  configuration 
for  use  in  resolving  the  feasibility  question.  The  information 
presented  here  was  largely  developed  by  FMSO  personnel  to  assist 


describing  the  baseline  system  for  the  -study. 
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2 .  NETWORK  CONFIGURATION 

FMSO  manages  major  logistics  data  bases  at  two  ICP's;  one 
at  the  Ship  Parts  Control  Center  (SPCC)  at  Mechanicsburg ,  Pa., 
and  the  other  at  the  Aviation  Supply  Office  (ASO)  at  Philadel¬ 
phia,  Pa.  The  SPCC  computer  complex  contains  two  U4  94  computers 
and  an  IBM  360/65.  The  ASO  computer  complex  contains  two  U494 
computers  and  a  Burroughs  3500.  At  each  ICP,  one  U494  supports 
real  time  processing  activity  for  an  Inventory  Control  (IC)  data 
base,  and  the  other  U494  supports  real  time  processing  for  a 
Weapons  System  (WS)  data  base.  At  both  locations,  each  U494  can 
access  the  other's  data  base  in  a  read  only  mode.  The  IBM  360/65 
maintains  a  Material  Maintenance  Management  (3M)  data  base,  and 
the  B3500  is  used  to  track  progress  of  high  priority  stock  trans¬ 
actions  for  air  logistics  support. 

Approximately  775  terminals  will  access  the  data  bases  through 
nin* programmable  communications  processors  used  as  comcentratcrs . 

Two  of  the  nine  concentrators  will  be  located  at  SPCC  for  local 
terminal  access,  and,  similarly,  two  will  be  located  at  ASO.  The 
remaining  five  concentrators  will  be  located  in  Washington,  D.C‘.  , 

San  Diego,  Calif.,  Oakland,  Ciaif.,  Jacksonville,  Fla.,  and  Norfolk, 
Va.  The  tentative  network  architecture  calls  for  each  of  the  con¬ 
centrators  to  be  dual-homed  to  the  two  ICP's.  An  estimate  of  the 
terminal  distribution  by  location  and  category  is  given  in  Table  1. 
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The  FEP's  will  serve  to  interface  the  mam  computers  at  tne 
ICP  with  the  remote  concentrators.  The  concentrator-FEP  connections 
are  tentatively  planned  to  be  through  dedicated  9600  bps  circuits. 
The  FEP-main  computer  connections  are  also  tentatively  planned  to 
be  through  dedicated  9600  bps  circuits,  although  other  alternatives, 
such  as  main  computer  channel  access,  are  currently  being  consid- 
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SYSTEM  OPERATION 
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The  system  operation  is  transaction  oriented,  with  two  basic 
types  of  transactions:  upquiries  to  update  the  data  base,  and 
inquiries  to  extract  information  from  the  data  base.  The  trans¬ 
actions  may  also  be  divided  into  those  requiring  real-time 
processing  and  those  which  may  be  grouped  for  batch  processing. 

For  convenierce,  we  will  identify  those  requiring  real-time 
processing  as  RTT's  (Real-Time  Transactions)  and  those  which  may 
be  grouped  for  batch  processing  as  PBT's  (Possibly-Batched  Trans¬ 
actions).  PBT's  are  batched  according  to  application  programs,  j 
with  a  processing  schedule  based  on  batch  size,  waiting  time,  and 
absolute  time.  * 

Both  RTT's  and  PBT's  may  enter  the  system  through  interactive  j 

.  3 

terminals.  Remote  Job  Entry  (RJE)  terminals  and  the  AUTODIN  inter?* 

-  ;'.j H 

face  are  assumed  to  enter  only  PBT's.  The  system  operation  is 
described  below  in  terms  of  these  three  methods  of  transaction 

] 

entry  and  the  handling  of  batched  transactions. 


3.1  Interactive  Terminals 


The  system  operation  is  best  described  in  terms  of  the  user 
activities  at  the  terminal.  The  initiation  of  an  upqu.iry  or  in¬ 
quiry  first  requires  establishment  of  communications  with  the 
system.  The  terminal  operator  does  this  by  initiating  a  request 
for  service  by  typing  the  North  Arrow  (t)  character.  This  signals | 
the  concentrator  that  a  new  activity  is  to  be  commenced,  and  the 
concentrator  signifies  its  ready  status  by  return  of  a  date  and 
time  response.  The  operator  then  enters  the  program  type  infor¬ 
mation  necessary  for  the  concentrator  to  verify  that  the  system 
will  support  the  indicated  activity.  An  affirmative  response  then 

a 

allows  the  terminal,  operator  to  enter  the  appropriate  data.  When 
this  activity  is  complete,  the  concentrator  has  within  it  the  trans 


action  (upquiry  or  inquiry)  for  transfer  to  the  appropriate  FEP 
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The  concentrator  then  adds  an  approporiate  routing  header  to  the 
transaction,  and  queues  the  transaction  with  other  transactions 
from  the  other  terminals,  for  transfer  to  the  appropriate  FEP. 

After  transfer  of  the  transaction  to  the  FEP  is  complete, 

theFEP  examines  the  transaction,  and  if  the  transaction  is  ident- 

.  ».  JfAM  €  r\.  ■  \  ,’r 

ified  as  an  RTT,  it  isLinimediately/ placed  on  queue,  for  transfer  to 

the  appropriate  main  computer.  If  the  transaction  is  identified 

as  a  PDT  it  is  placed  on  the  appropriate  application  queue,  and 

will  remain  there  until  the  application  batch  is  to  be  processed. 

Processing  of  transactions  by  the  main  computer  results  in 
outputs  to  be  returned  to  the  user.  These  outputs  are  immediately 
transferred  from  the  main  computers  to  the  FEP  where  they  are  then 
processed  to  determine  appropriate  routing,  and  queued  for  transfer 
to  the  appropriate  concentrator. 

The  current  design  of  the  concentrator  does  not  use  auxilliary 
storage  for  buffering.  Consequently,  the  FEP  must  queue  the  output 
until  the  concentrator  has  sufficient  buffering  available  for  the 
first  part  of  the  ouput  to  be  delivered  to  the  terminal.  Once  trans¬ 
fer  of  the  output  from  the  FEP  is  initiated,  the  concentrator  con¬ 
tinuously  delivers  the  output  to  the  terminal,  using  double  buffering 
to  enable  request  of  each  new  part  of  output  from  the  FEP  without 
interrupt  of  transmission  to  the  terminal.  The  life  cycle  of  the 
transaction  is  complete  when  the  last  character  of  the  ouput  is 
delivered  to  the  terminal. 

There  may  be  considerable  time  between  the  completion  of  trans¬ 
action  input  and  return  of  the  output.  During  this  time,  the  oper¬ 
ator  may  initiate  input  of  another  transaction.  If  this  is  done, 
transmission  of  an  output  to  the  terminal  must  wait  for  completion 
of  the  input  process. 
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3 . 2  Remote  Job  Entry 


3 . 3  AUTODIN  Entry 


The  FEP  will  receive  transactions  through  the  AUTODIN  inter- 
face.  These  transactions  will  basically  be  handled  by  the  FEP  in 


Several  RJE  terminals  (card  readers  plus  line  printers)  will 
be  connected  to  the  concentrators  to  facilitiate  entry  of  batched 
transactions.  In  this  mode  of  operation,  each  transaction  will  be 
on  one  card.  The  concentrator  will  simply  receive  the  transactions, 
determine  the  FEP  to  which  they  are  to  be  forwarded,  and  place  them 
on  the  appropriate  queue  for  transmission  to  the  FEP.  Because  the 
concentrator  does  not  have  auxilliary  storage  buffering,  provision 
must  be  made  for  the  concentrator  to  control  the  RJE  input  on  the 
basis  of  buffer  availability,  or  for  the  RJE  transactions  to  have 
sufficient  priority  to  ensure  that  their  transmission  to  the  FEP 
is  consistently  faster  than  their  input  to  the  concentrator. 

<yJX  Once  the  RJE  transactions  reach  the  FEP,  they  are  processed 
as  ordinary  PBT's.  This  processing  will  be  described  in  Section 
3.4.  Note  that  it  is  assumed  that  no  transactions  entered  by  RJE 
will  be  identified  as  RTT's. 


the  same  manner  as  transactions  received  from  RJE  terminals  through 
the  concentrator.  However,  additional  routing  and  AUTODIN  protocol 
.1  processing  will  be  necessary. 


The  FEP  will  receive  transactions  from  the  AUTODIN  interface 
and  from  the  concentrators.  As  the  transactions  are  received,  they 
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are  identified  as  RTT's  or  PBT's.  RTT's  are  immediately  placed  on 
queue  for  transfer  to  the  appropriate  main  computer.  PBT ' s  are 
placed  on  the  appropriate  application  queues. 

Each  application  queue  will  be  a  batch  for  processing  by  the 
appropriate  main  computer.  Each  batch  will  have  a  processing  sch¬ 
edule  that  may  be  based  on  batch  size,  waiting  time,  or  periodic 
processing.  Examples  of  such  rules  are: 


E 


i 


1.  Process  every  three  hours  or  whenever  the  batch 
reaches  fifty  transactions. 


2.  Process  whenever  the  ba£h<t  reaches  twenty  trans¬ 
actions  or  whenever  the  longest  waiting  transaction 
has  waited  six  hours. 


3.  Process  at  8:00  P.M. 


! 
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When  a  transaction  en  tered  through  a  concentrator  is  processed 
by  a  main  computer,  an  output  is  generated  for  retrun  to  the  user. 
This  output  is  immediately  transferred  to  the  FEP.  If  the  trans¬ 
action  was  an  RTT ,  the  output  is  immediately  queued  for  transfer 
to  the  appropriate  concentrator.  The  transfer  will  be  effected  as 
described  earlier. 

If  the  transaction  is  a  PBT,  the  output  will  be  destined  for 
a  line  printer.  The  outputs  are  queued  on  the  basis  of  destination, 
until  the  batch  processing  is  complete.  The  outputs  destined  for 
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line  printers  will  then  be  transferred  no  uie 
rators  with  the'  same  double  buffering  technique  desc 
for  RTT 1 s . 

Not  all  transactions  arriving  over  the  AUTCDIN 
outputs.  The  outputs  that  are  generated  will  be  imi 
ferred  to  the  FEP  where  they  will  be  queued  until  a 
message  is  formed  or  until  the  batch  processing  is 
FEP  processes  the  outputs  to  place  then  in  proper  A 
format,  and  then  transfers  the  message  to  the  AUTOU 
This  process  will  continue  until  alloutputs  have  ae 
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4.  FEP  FUNCTIONAL  DESCRIPTION 


The  functional  desciption  of  the  FEP  provided  by  FMSO  is  in¬ 
tended  to  be  as  machine  independent  as  possible.  The  description 
is  in  terns  of  functional  software  modules  organized  for  processing 
transactions  moving  upstream  in  the  system  and  outputs  moving  down- 
steam.  The  modules  may  be  viewed  as  application  programs  that  must 
be  properly  coordinated  by  an  FEP  executive. 

The  description  is  intended  to  serve  as  a  basis  for  developing 
theFEP  software.  The  implementation  of  the  FEP  should  be  guided  by 
tge  objective  of  minimal  reprogramming  of  the  concentrators  and  main 
computers.  Because  the  DCT  1000  protocol  is  currently  used  for  the 
main  computer/concentrator  interconnection,  this  objective  suggests 
use  of  the  DCT  1000  protocol  for  main  computer/FEP  interconnection 
and  for  the  FEP  concentrator  interconnection.  However,  if  other  al¬ 
ternatives,  such  as  the  Digital  Data  Communicatons  Message  Protocol 
(DDCMP)  or  direct  channel  access,  show  significant  advantage  with 
small  reprogramming  requirements,  they  may  be  used. 

A  brief  description  of  the  functional  processing  to  be  performed 
by  the  FEP  is  as  follows: 

t 

1.  Receive  messages  from  AUTODIN  host  processors  and  remote 
concentrators. 

2.  Create  a  stab  for  transactions  containing: 

a.  Date  and  time  stamp. 

b.  Input  routing  indicator. 

c.  Output  routing  indicator.  . 

d.  Internal  routing  indicators. 


e 


Transaction  identifier 


.  i  . 
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3.  Process  transactions  accoridng  to  internal  routing  indicate^ 

I 

4.  Queue  transactions  for  input  to  the  host  (either  immediate 
or  based  on  time  and/or  volume) . 

5.  Schedule  input  to  the  host. 

G.  Dequeue  transaction  for  delivery  to  host. 

7.  Transmit  transaction  to  the  host. 

8.  Queue  transaction  output  from  host. 

9.  Schedule  output  to  concentrators  and  Autodin. 

10.  Transmit  messages  to  concentrators. 

11.  Create  Autodin  messages. 

12.  Transmit  Autodin  messages  to  Autodin  interface  terminal. 

The  software  module  organization  identified  for  this  processing  is 
shown  in  Figure  2.  These  modules  are  briefly  described  below. 

4 . 1  Autodin  Interface  Module 

The  AUTODIN  interface  module  will  receive  transactions  from  the 
AUTODJ.N  CDC  1700  interface  terminal  processor.  The  protocol  for  this 
interface  is  not  yet  defined.  After  transmission  error  checking  is 
complete,  a  transaction  stub  will  be  created  indicating  date  and  time 
that  the  transaction  was  received  from  AUTODIN.  The  transaction  is 
then  forwarded  to  the  Input  Recongnition  module. 

The  output  function  of  the  AUTODIN  interface  module  will  be  to 
receive  line  blocks  from  the  AUTODIN  Message  Compiler  module,  and 
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transfer  them  to  the  AUTODIN  CDC  1700  interface  terminal  processor. 


4.2  Concentrator  Interface  Module 


The  Concentrator  Interface  module  will  allow  communication  be¬ 
tween  the  front-end  and  the  concentrators.  It  is  assumed 
that  all  of  the  concentrators  will  make  use  of  the  same  software 
package;  therefore,  only  one  line  protocol  technique  will  be  re¬ 
quired  in  the  front-end. 

The  Concentrator  Interface  module  will  receive  terminal  trans¬ 
actions  from  the  concentrators.  After  transmission  error  checking 
is  complete,  the  user's  identification  code  will  be  checked  against 
a  table  containing  all  valid  user's  of  the  system  at  that  location. 
If  the  user  is  valid,  a  transaction  stub  will  be  created  indicating 
date  and  time,  the  input  routing  indicator  and  the  output  routing 
indicator.  If  only  an  input  routing  indicator  is  present  in  the 
transaction  it  will  also  be  used  as  the  output  routing  indicator. 

If  the  user  is  not  a  valid  user  the  transaction  will  be  returned  to 
the  input  routing  indicator  with  an  error  message  indicating  the 
error  and  processing  of  the  transaction  will  terminate. 

The  transaction  with  its  stub  is  then  forwarded  to  the  Input 
Recognition  module. 

The  output  portion  of  the  module  will  receive  output  terminal 
messages  from  the  Queue/Dequeue  module.  After  blocking  message 
into  the  transmission  blocks,  it  sends  the  blocks  to  the  concentra¬ 
tor.  Output  messages  that  created  multiple  transmission  blocks  are 
to  be  interleaved  with  other  traffic  to  the  same  concentrator. 


4.3  Host  Interface  Module 


The  Host  Interface  module  will  have  the  responsibility  of  the 
communications  between  the.FEP  and  the  host  computers  (main  computers! 


If  possible,  a  common  .interlace  protocol  is  to  be  used  for  all  hosts, 
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with  the  protocol  for  DCT  1000  terminals  the  tentatively  planned  pro¬ 
tocol  because  of  its  current  support  in  the  U494  processors. 

The  Host  Interface  module  will  receive  transactions  from  the 
Queue/Dequeue  module  and  forward  them  to  the  proper  host  for  pro¬ 
cessing.  Output  from  the  host  will  be  forwarded  to  the  Queue/Dequeue 
module. 

4.4.  Input  Recognition  Module 

The  Input  Recognition  module  will  receive  all  transactions  from 
both  the  Concentrator  Interface  module  and  the  AIJTODIN  Interface 
module.  All  transactions  received  via  AUTODIN  will  have  the  trans¬ 
action  ID  added  to  the  transaction  stub  and  then  forwarded  to  the 
Queue/Dequeue  module. 

Transactions  received  via  the  concentrators  will  be  formatted 

'  1 

to  conform  to  one  of  the  standard  transaction  formats.  After  the 
transaction  is  in  the  proper  format,  the  type  of  the  transaction  will 
be  determined,  i.e. ,  upquiry  or  inquiry,  and  the  data  base  to  be 
affected.  This  information  is  compared  to  a' set  of  tables  to  determin 
if  the  user  is  authorized  to  complete  the  function  requested.  If  not, 
the  transaction  is  returned  to  the  input  routing  indicator  with  an 
indication  of  the  error  and  processing  is  terminated. 

If  the  user  is  authorized  to  complete  the  function,  the  internal 
routing  indicator  is  appended  to  the  stub  and  the  transaction  is  sent 
to  the  Queue/Dequeue  module. 

4 . 5  Queue/Dequeue  Module 

The  Queue/Dequeue  module  manages  the  transaction  queues.  All 
transactions  inputted  to  or  outputted  from  the  PEP  are  recorded  in 
mass  storage  files.  RTT 1 s  will  be  recorded  in  a  file  and  sent  to  the 
appropriate  host  at  the  same  time.  PBT's  will  be  recorded  in  queues 
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for  later  processing  as  directed  by  the  t^Lme  and/or  volume  cr  iter  it/ 

established  bv  the  unit.  A  queue  table^will  be  maintained  for  each 

* 

type.  Each  entry  will  contain  the  first  record  to  be  processed  from 
the  queue  and  the  total  number  of  entries  in  the  queue./ 

The  mass  storage  will  also  be  used  to  buffer,  queue,  and  file 
output  messages  from  the  host.  •  Only  a  single  storage  allocation 
should  be  required  to  serve  all  three  of  these  storage  functions. 

A  copy  of  the  queue  tables  will  also  be  maintained  on  the  mass  storage 

4.6  Scheduler  Module 

The  Scheduler  module  will  constantly  monitor  the  queue  table  to 
insure  that  all  transactions  are  processed  according  to  the  scheduling 
criteria  established  by  the  unit.  All  scheduling  criteria  will  be 
contained  in  tables  which  specify  the  transaction  type,  input  routing 
indicator  and  time  and/or  volume  information.  The  Scheduler  module 
upon  detecting  a  queue  to  be  processed  will  send  a  request  to  the 
Queue/Dequeue  module  containing  the  queue  to  be  processed  and  the 
destination  of  the  contents. 

4 . 7  AUTODIN  Message  Compiicr  Module  % 

► 

The  Autodin  Message  Compiler  module  will  receive  transactions 
from  the  Queue/Dequeue  module  as  directed  by  the  Scheduler  module. 

A  standard  AUTODIN  header  with  routing  address  will  be  appended  to 
the  front  of  the  AUTODIN  message.  When  a  predetermined  number,  set 
by  the  unit,  of  transactions  have  been  sent  to  the  AUTODIN  Interface 
module,  a  AUTODIN  trailer  will  be  appended  to  the  end  of  the  AUTODIN 
message.  The  AUTODIN  Message  Compiler  will  repeat  the  process  until 
the  queue  is  empty.  The  predetermined  number  of  transactions  is  an 
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upper  limit;  provisions  will  be  made  to  send  fewer  transactions  when 
required. 
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5.  TRAFFIC 

Transactions  arrive  at  the  FEP  through  either  the  AUTODIN 
interface  or  the  concentrator  interfaces.  All  entry  mechanisms 
may  be  used  for  both  inquiries  and  upquiries.  Although  the  precise 
mix  of  traffic  is  not  known,  it  is  known  that  inquiries  are  much  more 
frequent  than  upquiries.  Consequently,  it  will  be  assumed  that 
80%  of  the  traffic  from  any  source  will  be  inquiries,  and  20%  up-- 
quiries. 

Transactions  arriving  through  the  AUTODIN  interface  are  PBT's, 
and  have  constant  80  column  card  image  size.  AUTODIN  upquiries  do 
not  result  in  an  output. 

AUTODIN  inquiries  result  in  outputs  that  are  also  constant 
80  column  card  image  size. 

Transactions  arriving  through  the  concentrator  interfaces 
may  have  originated  at  RJE  terminals  or  interactive  terminals. 
Transactions  originating  at  RJE  terminals  have  an  average  input 
length  of  100  characters,  with  an  assumed  uniform  distribution 
from  50  to  150  characters.  Outputs  generated  by  upquiries  simply 
echo  the  inputs,  while  outputs  generated  by  inquiries  have  an  * 
average  message  length  of  2000  characters,  assumed  uniformly 
distributed  from  1000  to  3000  characters. 

Transactions  originating  at  interactive  terminals  may  be 
either  PBT's  or  RTT's,  and  have’  a  length  of  approximately  50 
characters  average,  with  an  assumed  uniform  distribution  from 
40  to  60  characters.  As  before,  upquiries  result  in  outputs 
that  are  simply  an  echo  of  the  inputs.  Inquiries  result  in  out¬ 
puts  that  have  an  average  length  of  520  characters,  with  an 
assumed  uniform  distribution  from  220  characters  to  820  characters. 

The  nominal  demand  placed  on  the  system  is  based  on  the 
following  activity  levels  for  the  different  entry  mechanisms: 
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1.  Teletypes  (110bps)  enter  20  transactions  per  hour. 


2.  CRT's  (1200bps)  enter  35  transactions  per  hour. 


PW,/1 


3.  RJE's  (4800bps)  enter  15  transactions  per  hour. 

-  4.  I  AUTODINyenters  50,000  transactions  per  day,  of  which 
)  20%,  30%,  40%  and  50%  are  to  be  investigated  as  peak  hour 
factors. 


An  indication  of  local  terminal  response  time  is  to  be  determined 
for  30%,  40%,  50%,  60%,  and  70%  of  the  interactive  terminal  trans¬ 
actions  being  RTT's. 

Approximately  90%  of  the  traffic  entered  through  the  four  loca 
concentrators  of  the  ICP's  will  go  “to  their  respective  ICP  processor 
with  the  remaining  10%  directed  to  the  processors  at  the  other  ICP.  j 
The  traffic  from  the  five  remote  concentrators  will  have  approximate! 
56%  of  the  transactions  directed  to  ASO  and  44%  to  SPCC. 

Approximately  56%  of  the  traffic  into  the  SPCC  main  computers  | 
will  be  directed  to  the  ICS  machine,  35%  to  the  WEPS  machine, .and 
to  the  3M  machine.  Traffic  into  the  ASO  machine  is  currently  averag 
71%  to  the  ICS  machine,  29%  to  the  WEPS  machine,  with  the  B3500  yet 
to  be  integrated  into  the  on-line  operations.  .  j 
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PROPOSED  FEP  SYSTEM  CONFIGURATION 


To  determine  the  feasibility  of  using  a  minicomputer-based 
system  for  the  FEP,. a  PDP  11  configuration  has  been  proposed  as 
a  baseline  system  for  investigation.  The  configuration  is  based 
on  dual  PDP  11/70  CPU's  sharing  dual  ported  disks  and  line  con¬ 
trollers  to  operate  in  a  load  sharing  or  hot  standby  mode.  For 
purposes  of  evaluation,  a  hot  standby  mode  will  be  assumed. 

The  system  configuration  is  graphically  portrayed  in 
Figure  3,  and  contains  the  following  hardware  elements: 


1.  Two  PDP  11/70  CPU's  with  2K  byte  cache  memory,  128K 
byte  core,  line  frequency  clock,  DECwriter  and  interface, 


2.  Two  (2)  TWU16-EA  program  selectable  1600/800  bpi 
magnetic  tape  transports  and  control  units  (nine  track  industr 
compatible,  45  ips) , 


3.  Two  (2)  RWP04-BA  88  million  byte  disk  drives  with  dual 
access,  and  two  (2)  PDP  11/70  control  units, 


One  (1)  DV11-AA  synchronous  communication  multiplexer 


with  two  (2)  DV11-BA  eight-line  termination  units  and  provisio 


for  dual  processor  control. 


For  total  redundancy,  an  extra  communications  multiplexer  should 
be  available.  However,  there  does  not  appear  to  be  available 
standard  DEC  hardware  for  online  redundancy  of  this  component. 

Standard  DEC  operating  systems,  such  as  the  RSX-11M,  and 
communications  software  modules,  such  as  in  COMTEX,  are  envisioned 
for  the  basic  system  software*  The  functional  modules  defined  in 
Section  4  would  be  developed  as  application  tasks. 


The  proposed  configuration  described  above  is  based  on  a 
communications  interface  with  the  main  computers.  It  may  be 
more  appropriate  to  use  a  direct  channel  interface  with  the  FEP 
emulating  a  standard  channel  device  of  the  main  computers.  This 
type  of  interface  appears  feasible  for  the  PDP-11  system,  but  not 
available  as  a  standard  DEC  product. 
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7 .  CONCLUSION 

This  memorandum  has  presented  a  preliminary  description  of 
the  system  environment  for  a  Front  End  Processor  in  the  Navy 
Logistics  Data  Communications  Network.  The  description  should 
serve  as  a  framework  for  refinement  into  a  detailed  description 
on  which  the  feasibility  study  can  be  based. 
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FIGURE  3:  A  PROPOSED  FEP  HARDWARE  CONFIGURATI 


Network  Amlyr.is  Corporal 


LOGISTICS  DATA  COMMUNICATIONS 
9  REMOTE  CONCENTRATORS  AND  773  TERMINAL  LOCATIONS 

(PROPOSED) 


PHASE  II 


TERMINAL  SPEEDS 


4 

(MUDS) 

CRT 

RJE 

TTY 

LOCATION 

300<X<2400 

2400<X<9600 

X<300 

NORFOLK,  VA 

NSC  NORVA 

.  (X 

2 

=  Baud  Rate) 

NAS  NORVA 

2 

NARF  NORVA 

2 

1 

1 

AIR1.ANT/ AMO 
-REPLANT.  _ 

2 

4 

2 

1 

NSY  NORVA 

SAFETY  CENTER 

2 

1 

- 

NAVSEC  NORDIV 

3 

1 

NOSSOLANT 

NAILSC 

2 

2 

1 

NMCF  YOR1CTOWN 

1  . 

SERVLANT 

2 

NAS  PAX 

2 

1 

NAS  OCEANA 

1 

1 

PHIBLANT 

2 

% 

t FOSATLANT 

1 

1 

WASH,  DC 

NAVSEC,  ANNAPOLIS 

2 

NAVORD 

3 

1 

2 

NAVSEA 

4 

2 

4 

NAVELEX 

10 

2 

10 

NAVSEC 

•  6 

2 

9 

NAVAIR 

5 

2  ■ 

3 

CNO 

3 

1 

CENO,  HI 

3 

1 

2 

TABLE  Is  TERMINAL  DISTRIBUTION 
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NAVELEX  PORTS 
PERA  ASW 
PERA  SS 
PERA  AAW 
ASO 
NAEC 
NATSF 
NSY  PHILA 
NAVSEC  PHILA 
NSY  PORTS 
NAS  BRUNSWICK 
CBC  DAVISVILLE 
NUSU  NPT 
SUBLON 

NAS  LAKEIIURST 


SPCC 


SPCC 

NAVSEC,  MECJI 

NAVILCO 

MSO 

PWC  GREAT  LAKES 
NAFI 


SAN  DIEGO 


NSY  LBEACH 
NSC  SD 
NAS  NORIS 
N/\RF  NORIS 
REPAC 
MSDO 

AIRPAC/AMO 
NAVSEC  WEST 
NOSSOPAC 
NAVELEX,  SD 
EL  TORO 
NAS  MIRAMAR 
NSC  PEARL 
PHIBPAC 
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OAKLAND 

NSMSE5 

FM5AEG,  CORONA 
NAVE  LEX ,  OAIC 
NSY  HARE  IS 
NAIIF  ALAMEDA 
NAS  ALAMEDA 
NSC  OAKLAND 
NWS  CONCORD 
NSY  PUGET 
NSC  PUGET 
PT  MUGU 
PT  miENEME 
NAS  MOFFETT 
NAS  WHIDBEY 
CHINA  TAKE 
PERA  CV 

JACKSONVILLE 

NAVELEX,  CHARLESTON 
NAS  PENS  .OLA 
-  NARF  PENSACOLA 
NAS  JACKSONVILLE 
NARF  JACKSONVILLE 
NSC  CHARLESTON 
MCAS  CHERRY  POINT 
NARF  CHERRY  POINT 
NOS  LOUISVILLE 
NAS  CECIL 
‘NAS  ALBANY 
NAS  MAYPORT 
NAS  CORPUS 
CNATRA 
CNET 

NAS  MEMPHIS 
NAS  KEY  WEST 
NTC  ORLANDO 
CBC  GULFPORT 

FONTS 

NALDA 


